In a typical client/server voice communication network, multiple IP phones communicate with a PBX using Transmission Control Protocol (TCP) connections. The IP phones connect to the PBX using a 3-stage process. The process generally includes acquiring a TCP link to the PBX usually requiring a three-way handshake, making a secure connection and creating a control link with the PBX (ie. registration). IP phones that rely on stimulus messaging generally require a persistent TCP control link to their PBX.
During certain events, such as recovery from a power failure, for example, the PBX may become flooded when a large number of IP phones attempt to establish connections at the same time. The large number of SYN packets in the queue along with other messages results in the requesting IP phones waiting a long time prior to establishing a connection with the PBX.
PBX connection delays for all IP phones are exacerbated by the addition of security protocols, such as Secure Sockets Layer (SSL). Processing SSL connections is time-consuming due to the large number of computations required in creating keys, which have the highest level of security, as required by IP phones. As such, the PBX generally limits the number of IP phones able to simultaneously attempt SSL connections and refuses further SSL attempts once the quota for the PBX has been reached. It is common in such circumstances for IP phones to be turned away, forced to disconnect their TCP connection and attempt a 3-way handshake on a non-secure cleartext port of the PBX.
Once an IP phone connects to a secure or non-secure port, it registers with the PBX and provides its device capabilities in the registration request. If the IP phone is on an unsecure port yet advertises that it supports SSL, the PBX may reject the registration request and force the IP phone to disconnect in order to retry the SSL connection. If the PBX accepts the registration, it will send the IP phone a large number of stimulus commands to configure the IP phone to be able to make and accepts phone calls. The large internal messaging flows associated with the configuration for large bursts of IP phones may result in significant degradation of PBX performance.
Allowing a large number of IP phones to connect to the PBX in a random manner is an inefficient and lengthy process. One solution is to optimize the number of TCP SYN packets that each phone sends out. Limiting the amount of time that the IP phones attempt to connect to the PBX to, say 10 seconds, concentrates the transmission of SYN packets to a short period. If the phones are allowed to attempt to connect for longer periods, the SYN packets will be spaced out with long delays due to the random backoff scheme that TCP employs.
The trend in the telecommunications industry is to provide client/server networks that are able to support more and more phones per PBX. As such, the total time required to connect all of the IP phones continues to grow. It is desirable to minimize the amount of time required for each IP phone to establish a connection with the PBX and therefore minimize the total connection time.